The Secure Sockets Layer (SSL) protocol allows applications to communicate across a network in a way designed to prevent eavesdropping, tampering, and message forgery. SSL provides endpoint authentication and communications privacy over the Internet using cryptography.
However, SSL-enabled clients typically match the CN (“common name”) element of the subject name of the server's SSL certificate against the requested server name, and report any mismatch to the user. For example, visiting a server under development causes two error dialogs to occur—one because the certificate is self-signed, and one because the browser is expecting one name, but is getting a certificate with a different name. The second error dialog displays both the expected and the received server names.
Another problem is that the authentication of the CN element of the subject name is a convention, and it is not required by the SSL standard. There is no structural requirement on the CN element that dictates that it holds a server name. In fact, for personal SSL certificates (such as the ones used to sign email), the CN field typically contains the owner's legal name. It can hold any printable string of just about any length.
As such, when migrating services to a new server, it is not unusual to use a new server name. Indeed, it may be required, if both servers are to be operational for some overlapping period of time. When the old server is no longer to be used, it cannot ordinarily just be shut off because its old users may have configuration that depends on the old name (browser bookmarks, email account server settings, etc).